packages/core/src/core/processor.ts (1)

Line range hint 140-165: Prompt construction is thorough but watch for potential injection.
If user input is included without sanitization, malicious content might alter your prompt in unexpected ways. Consider sanitizing or bounding user-provided content to prevent injection attempts.

-const contentStr = ...
+const sanitizedContent = sanitizeContent(contentStr);
+const prompt = ...

packages/core/src/core/processor.ts (5)

13-50: Solid approach to an abstract BaseProcessor.
By defining BaseProcessor with canHandle() and process() as abstract methods, you've cleanly enforced a contract for specialized processors. This design fosters extensibility when multiple processors are added. Consider adding inline documentation or test coverage to ensure all subclasses meet the contract consistently.

---

52-70: MessageProcessor extends BaseProcessor effectively.
The constructor and call to super() are correct. However, consider improving the TODO: fix this placeholder in canHandle() so it doesn’t always return true. If it's truly universal, rename or remove the TODO.

---

75-109: Consider removing or refactoring the commented-out logic.
Large blocks of commented-out code can confuse future maintainers. If you plan on reviving it, track it in version control or place it behind a feature flag. Otherwise, remove it and rely on source history.

---

280-289: Robust error handling on LLM processing failures.
Returning a partial ProcessedResult ensures the rest of the system can continue without throwing unhandled exceptions. Consider logging more context if repeated failures occur or add metrics for observability.

---

298-364: Remove or convert commented-out logic into a plugin/feature-flag system.
Leaving large chunks of commented code can create confusion. Store any transitional features in version control or place behind a toggle if you plan to reintroduce them soon.

packages/core/src/core/orchestrator.ts (3)

49-53: Populate processor map by name while ensuring uniqueness.
Consider validating that the name is non-duplicate or raising an error if a name collision occurs.

---

71-119: processContent method is well-structured and easy to follow.

1. It confirms room existence.
2. It locates the first capable processor.
3. If none is found, logs a fallback.
   Consider letting the user specify which processor to apply or fallback to a default for more fine-grained control.

---

Line range hint 304-364: Multi-processor workflow in runAutonomousFlow is well-implemented.
Looping until queue is empty ensures that new content from actions is fully processed. Consider whether you might need concurrency control in high-throughput environments.

examples/example-api.ts (1)

63-63: LGTM! Architecture improvement.

The change to accept an array of processors ([processor]) aligns with the PR objective of enabling multiple processors. This enhancement provides better extensibility and flexibility in processing pipelines.

packages/core/src/core/utils.ts (2)

255-264: Add configuration options for time thresholds.

The function has hardcoded time thresholds. Consider making these configurable to support different use cases.

+interface TimeThresholds {
+  veryRecent: number; // hours
+  recent: number;
+  thisWeek: number;
+  thisMonth: number;
+}
+
+const DEFAULT_TIME_THRESHOLDS: TimeThresholds = {
+  veryRecent: 24,
+  recent: 72,
+  thisWeek: 168,
+  thisMonth: 720,
+};
+
-export function getTimeContext(timestamp: Date): string {
+export function getTimeContext(
+  timestamp: Date,
+  thresholds: TimeThresholds = DEFAULT_TIME_THRESHOLDS
+): string {
   const now = new Date();
   const hoursDiff = (now.getTime() - timestamp.getTime()) / (1000 * 60 * 60);

-  if (hoursDiff < 24) return "very_recent";
-  if (hoursDiff < 72) return "recent";
-  if (hoursDiff < 168) return "this_week";
-  if (hoursDiff < 720) return "this_month";
+  if (hoursDiff < thresholds.veryRecent) return "very_recent";
+  if (hoursDiff < thresholds.recent) return "recent";
+  if (hoursDiff < thresholds.thisWeek) return "this_week";
+  if (hoursDiff < thresholds.thisMonth) return "this_month";
   return "older";
 }

---

299-303: Consider adding type information for better type safety.

The relevantData object could benefit from explicit type information to prevent potential runtime errors.

+interface RelevantData {
+  content: any;
+  type?: string;
+}
+
-const relevantData = {
+const relevantData: RelevantData = {
   content: item.content || item,
   type: item.type,
 };

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

packages/core/src/core/processor.ts (1)

Line range hint 74-264: Consider refactoring for better maintainability.

The process method is quite long and handles multiple responsibilities. Consider:

1. Extract schema construction to separate methods
2. Move prompt template to a separate file
3. Extract LLM response handling logic

+private constructOutputSchema(outputs: IOHandler[]): string {
+    return outputs
+        .map((handler) => 
+            `${handler.name}: ${JSON.stringify(zodToJsonSchema(handler.schema, handler.name))}`)
+        .join("\n");
+}

+private constructPrompt(content: any, otherContext: string, ioContext?: {
+    availableOutputs: IOHandler[];
+    availableActions: IOHandler[];
+}): string {
+    const contentStr = typeof content === "string" ? content : JSON.stringify(content);
+    const outputsSchemaPart = ioContext?.availableOutputs 
+        ? this.constructOutputSchema(ioContext.availableOutputs)
+        : "";
+    const actionsSchemaPart = ioContext?.availableActions
+        ? this.constructOutputSchema(ioContext.availableActions)
+        : "";
+    
+    return `Analyze the following content...`; // Move template to separate file
+}

 async process(
     content: any,
     otherContext: string,
     ioContext?: {
         availableOutputs: IOHandler[];
         availableActions: IOHandler[];
     }
 ): Promise<ProcessedResult> {
     this.logger.debug("Processor.process", "Processing content", {
         content,
     });

-    const contentStr = typeof content === "string" ? content : JSON.stringify(content);
-    // ... rest of the implementation
+    const prompt = this.constructPrompt(content, otherContext, ioContext);

packages/core/src/core/room-manager.ts (1)

229-251: LGTM! Consider adding input validation and documentation.

The implementation looks good with proper error handling and data mapping. Consider these minor improvements:

1. Add JSDoc documentation describing the method's purpose and parameters
2. Add input validation for negative limit values

+/**
+ * Retrieves memories from a specific room.
+ * @param roomId - The ID of the room to fetch memories from
+ * @param limit - Optional maximum number of memories to retrieve
+ * @returns Promise resolving to an array of Memory objects
+ */
 public async getMemoriesFromRoom(
     roomId: string,
     limit?: number
 ): Promise<Memory[]> {
+    if (limit !== undefined && limit < 0) {
+        throw new Error("Limit cannot be negative");
+    }
     if (!this.vectorDb) {
         throw new Error("VectorDB required for getting memories");
     }

packages/core/src/core/vector-db.ts (1)

1675-1708: LGTM! Consider adding sorting and filtering options.

The implementation is solid with good error handling and logging. Consider these enhancements:

1. Add sorting options (e.g., by timestamp)
2. Add metadata filtering capabilities
3. Add JSDoc documentation

+/**
+ * Gets all memories from a specific room's collection.
+ * @param roomId - The ID of the room to fetch memories from
+ * @param limit - Optional maximum number of memories to retrieve
+ * @param options - Optional parameters for sorting and filtering
+ * @returns Promise resolving to an array of memories with content and metadata
+ */
 public async getMemoriesFromRoom(
     roomId: string,
-    limit?: number
+    limit?: number,
+    options?: {
+        sortBy?: { field: string; order: 'asc' | 'desc' };
+        where?: Record<string, any>;
+    }
 ): Promise<{ content: string; metadata?: Record<string, any> }[]> {
     try {
         const collection = await this.getCollectionForRoom(roomId);

         // Get all documents from the collection, with optional limit
         const results = await collection.get({
             limit,
+            where: options?.where,
             include: ["documents", "metadatas"] as IncludeEnum[],
         });

         if (!results.ids.length) {
             return [];
         }

+        let memories = results.ids.map((_, idx) => ({
+            content: results.documents[idx] || "",
+            metadata: results.metadatas?.[idx] || {},
+        }));
+
+        // Apply sorting if specified
+        if (options?.sortBy) {
+            memories.sort((a, b) => {
+                const aVal = a.metadata?.[options.sortBy!.field];
+                const bVal = b.metadata?.[options.sortBy!.field];
+                return options.sortBy!.order === 'asc' 
+                    ? (aVal > bVal ? 1 : -1)
+                    : (aVal < bVal ? 1 : -1);
+            });
+        }
+
+        return memories;

examples/example-twitter.ts (1)

106-113: LGTM! Consider adding type safety for metadata.

The return structure improvements add valuable context. Consider:

1. Define a specific type for the mention metadata instead of using any
2. Update the schema to validate the metadata structure

+interface TwitterMentionMetadata {
+    conversationId: string;
+    tweetId: string;
+    username: string;
+    timestamp: string;
+}

 return mentions.map((mention) => ({
     type: "tweet",
     room: mention.metadata.conversationId,
     messageId: mention.metadata.tweetId,
     user: mention.metadata.username,
     content: mention.content,
-    metadata: mention,
+    metadata: mention as TwitterMentionMetadata,
 }));

 schema: z.object({
     type: z.string(),
     room: z.string(),
     user: z.string(),
     content: z.string(),
-    metadata: z.record(z.any()),
+    metadata: z.object({
+        conversationId: z.string(),
+        tweetId: z.string(),
+        username: z.string(),
+        timestamp: z.string(),
+    }),
 }),

Also applies to: 117-118

packages/core/src/core/processor.ts (1)

12-49: LGTM! Consider enhancing error handling and documentation.

The abstract class provides a good foundation. Consider:

1. Add JSDoc for abstract methods
2. Add error handling guidelines for implementations

 export abstract class BaseProcessor {
     protected logger: Logger;

     constructor(
         protected metadata: { name: string; description: string },
         protected loggerLevel: LogLevel = LogLevel.ERROR,
         protected character: Character,
         protected llmClient: LLMClient
     ) {
         this.logger = new Logger({
             level: loggerLevel,
             enableColors: true,
             enableTimestamp: true,
         });
     }

     public getName(): string {
         return this.metadata.name;
     }

+    /**
+     * Determines if this processor can handle the given content.
+     * @param content - The content to check
+     * @returns true if the processor can handle the content, false otherwise
+     * @throws {Error} if content validation fails
+     */
     public abstract canHandle(content: any): boolean;

+    /**
+     * Processes the given content and returns a result.
+     * @param content - The content to process
+     * @param otherContext - Additional context for processing
+     * @param ioContext - Optional context with available handlers
+     * @returns Promise resolving to the processed result
+     * @throws {Error} if processing fails or validation errors occur
+     */
     public abstract process(
         content: any,
         otherContext: string,
         ioContext?: {
             availableOutputs: IOHandler[];
             availableActions: IOHandler[];
         }
     ): Promise<ProcessedResult>;

packages/core/src/core/orchestrator.ts (2)

4-4: Remove unused import MessageProcessor.

The MessageProcessor type is imported but never used in this file.

-import type { BaseProcessor, MessageProcessor } from "./processor";
+import type { BaseProcessor } from "./processor";

---

254-262: Improve processor selection and error handling.

Two suggestions for improvement:

1. Extract processor finding logic into a reusable method
2. Uncomment the warning log for better debugging when no processor is found

-// 2) Find the first processor that can handle it
-const processor = Array.from(this.processors.values()).find((p) =>
-    p.canHandle(data)
-);
+// 2) Find the first processor that can handle it
+const processor = this.findSuitableProcessor(data);

+private findSuitableProcessor(data: unknown): BaseProcessor | undefined {
+    return Array.from(this.processors.values()).find((p) =>
+        p.canHandle(data)
+    );
+}

 if (!processor) {
-    // this.logger.warn("No processor found for data", { source });
+    this.logger.warn("No processor found for data", { source });
     continue;
 }

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

packages/core/src/core/processors/message-processor.ts (3)

12-28: Consider making the processor name configurable.
Right now, the constructor hardcodes "message" as the processor name in its metadata. If you plan to add more message-like processors in the future, you might benefit from passing in a configurable name to avoid confusion.

- name: "message",
+ name: processorName ?? "message",

---

35-105: Extract prompt-building into a separate method.
The process method constructs a lengthy prompt inline, making it cumbersome to maintain. Consider moving this logic into a dedicated helper inside this class or a utility file.

async process(...) {
-    const prompt = `Analyze the following content...` // many lines
+    const prompt = this.buildPrompt(contentStr, otherContext, ioContext);
     ...
}

private buildPrompt(contentStr: string, otherContext: string, ioContext?: ...): string {
    return `Analyze the following content...`;
}

---

107-225: Include error details or logs in the fallback object.
Currently, the catch block sets a generic fallback with minimal metadata. Including at least the error message or a truncated stack trace could help downstream debugging.

- return {
-    content,
-    metadata: {},
-    ...
- };
+ return {
+    content,
+    metadata: { error: String(error) },
+    ...
+ };

packages/core/src/core/processor.ts (2)

13-28: Emphasize usage guidelines for metadata.
Currently, metadata is flexible but might need constraints. If future processors rely on certain structure, consider validating or partially typing it within the constructor.

---

50-68: Use stronger types for the content parameter.
Both canHandle and process accept content: any, which can lead to runtime errors if the data structure differs from expectations. Consider introducing a generic or union type if feasible.

packages/core/src/core/room-manager.ts (2)

253-274: Fix incorrect method name in error log.

The error log message uses markContentAsProcessed instead of hasProcessedContentInRoom.

Apply this diff to fix the error log message:

-                "RoomManager.markContentAsProcessed",
+                "RoomManager.hasProcessedContentInRoom",

---

276-301: Add return type annotation for better type safety.

The method's return type can be explicitly annotated for better type safety and documentation.

Apply this diff to add the return type annotation:

-    public async markContentAsProcessed(
+    public async markContentAsProcessed(
         contentId: string,
         roomId: string
-    ): Promise<boolean> {
+    ): Promise<boolean> {

packages/core/src/core/orchestrator.ts (2)

241-335: Consider implementing rate limiting for the processing queue.

The queue processing loop could benefit from rate limiting to prevent overwhelming the system when processing large arrays of data.

Apply this diff to add rate limiting:

 while (queue.length > 0) {
     const { data, source } = queue.shift()!;
+    
+    // Add rate limiting
+    if (queue.length > 0) {
+        await new Promise((resolve) => setTimeout(resolve, 100));
+    }

     const processedResults = await this.processContent(data, source);

---

541-563: Consider extracting the delay value to a configurable constant.

The hardcoded delay value of 5000ms in the array processing loop should be configurable.

Apply this diff to make the delay configurable:

+private static readonly BATCH_PROCESSING_DELAY_MS = 5000;
+
 public async processContent(
     content: any,
     source: string
 ): Promise<ProcessedResult[]> {
     if (Array.isArray(content)) {
         const allResults: ProcessedResult[] = [];
         for (const item of content) {
             // (Optional) Delay to throttle
-            await new Promise((resolve) => setTimeout(resolve, 5000));
+            await new Promise((resolve) => 
+                setTimeout(resolve, Orchestrator.BATCH_PROCESSING_DELAY_MS)
+            );

packages/core/src/core/vector-db.ts (1)

1672-1708: Consider adding sorting options for memory retrieval.

The getMemoriesFromRoom method could benefit from sorting options to allow retrieval of memories in chronological order or by other metadata fields.

Apply this diff to add sorting options:

 public async getMemoriesFromRoom(
     roomId: string,
-    limit?: number
+    limit?: number,
+    sortBy?: { field: string; order: 'asc' | 'desc' }
 ): Promise<{ content: string; metadata?: Record<string, any> }[]> {
     try {
         const collection = await this.getCollectionForRoom(roomId);
+        const orderBy = sortBy ? { [sortBy.field]: sortBy.order } : undefined;

         const results = await collection.get({
             limit,
+            orderBy,
             include: ["documents", "metadatas"] as IncludeEnum[],
         });

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

packages/core/src/core/index.ts (1)

22-40: Consider maintaining consistent alphabetical ordering of exports.

While most exports follow alphabetical order, there are some inconsistencies. Consider reordering for better maintainability:

export {
    BaseProcessor,
    Chains,
-   ChainOfThought,
    ChromaVectorDB,
    Consciousness,
    defaultCharacter,
    GoalManager,
    IO,
    LLMClient,
    Logger,
    Orchestrator,
    Processors,
    Providers,
    Room,
    RoomManager,
    StepManager,
    TaskScheduler,
    Types,
    Utils,
};

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro